…and source code generation

Only conflict was the import block in Kotlin/language.ts: kept master's
ESM .js import paths and re-added the PR's type imports
(PrimitiveStringTypeKind, TransformedStringTypeKind, StringTypeMapping)
in the same style.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Register strict ISO converters on the generated ObjectMapper for
OffsetDateTime, LocalDate and OffsetTime via the existing convert()
infrastructure instead of requiring jackson-datatype-jsr310: the
module's serializers don't round-trip faithfully (OffsetTime pads
"23:20:50.52Z" to "23:20:50.520Z"), while the ISO formatters do,
and this way generated code needs no extra dependency.

Also fix union deserialization when several members are guarded by the
same node type: date, time, date-time and enum values are all TextNode,
so the previous output had duplicate 'is TextNode ->' branches of which
only the first could ever match. Members sharing a guard now parse in
a single branch that tries each member in sequence, strictest first
(transformed strings, then enums, then plain strings).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The klaxon renderer's matchType calls were missing the
transformedStringType matcher the base renderer maps to java.time
types, so any schema with date/time formats in a union crashed
generation with "Unsupported type date-time in non-exhaustive match".
Add the matchers, register Klaxon converters that parse the java.time
types from ISO strings and re-serialize them via the ISO formatters
(exact round-trip), and give union members that share the 'is String'
guard the same sequential-parse treatment as the Jackson renderer.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…va.time

With date/time inference now mapping to java.time types, two groups of
misc inputs fail the round-trip comparison: files with non-RFC3339
date-times (space-separated, no offset) that OffsetDateTime.parse
rejects, and files whose fractional seconds have trailing zeros that
the ISO formatters legitimately trim (".000Z" -> "Z"). Skip them for
both Kotlin variants, mirroring what Go already does for the first
group.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…es-2845

…erence

With the default recognizer now requiring RFC 3339 (T separator and
timezone offset), space-separated timestamps like "2013-06-15 21:10:28"
are inferred as plain strings, so these eight misc fixtures round-trip
for both kotlin variants without skips (verified per file; f6a65.json
also verified end-to-end with kotlinc).

The nine remaining skips are unchanged: their values are RFC 3339-valid
but carry trailing-zero fractional seconds (e.g. ".000Z") that
java.time does not re-serialize identically.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

The Kotlin language's stringTypeMapping maps JSON Schema date, time, and
date-time formats to java.time types for every framework, but the
kotlinx renderer was never taught about them: it emitted @serializable
data classes with OffsetDateTime/LocalDate/OffsetTime properties, which
don't compile because kotlinx.serialization has no built-in serializers
for java.time ("Serializer has not been found for type
'OffsetDateTime'").

Emit custom KSerializer objects for the java.time types that appear in
the type graph and register them file-wide with @file:UseSerializers.
Like the Jackson and Klaxon converters, they parse with .parse and
format with the ISO formatters so values round-trip faithfully.

There is no kotlinx fixture in CI, so cover this with a unit test
asserting the serializers and file annotation are emitted (and not
emitted when no date/time types occur).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

# Conflicts:
#	packages/quicktype-core/src/language/Kotlin/KotlinJacksonRenderer.ts
#	packages/quicktype-core/src/language/Kotlin/KotlinKlaxonRenderer.ts
#	packages/quicktype-core/src/language/Kotlin/KotlinXRenderer.ts

…erence

Merging master brought in the kotlinx fixture coverage from #2950,
whose skip lists were tuned against master, where Kotlin had no
date-time support. With this branch's date/time mapping:

- Declare the "date-time" feature for KotlinXLanguage. date-time.schema
  itself stays skipped because its union-array properties hit the
  kotlinx sealed-class union limitation; the emitted KSerializers are
  exercised by JSON inputs with inferred date-times instead.
- Skip the misc JSON inputs whose date-times carry trailing zeros in
  the fractional seconds, which java.time doesn't re-serialize
  identically — the same set already skipped for klaxon and jackson.
- Skip date-time-or-string.schema: its string|date-time property was a
  plain string before and now becomes a union.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Instead of skipping test inputs whose date-time strings java.time does
not re-serialize byte-identically, give Kotlin a DateTimeRecognizer
(the existing facility for this, mirroring SwiftDateTimeRecognizer)
that refuses to infer date/time types from such strings in the first
place. Rejected strings simply stay plain strings.

The rules, all verified against java.time's actual parse/format
behavior (ISO_LOCAL_DATE / ISO_OFFSET_TIME / ISO_OFFSET_DATE_TIME):

- no trailing zeros in fractional seconds (java.time formats the
  shortest fraction: ".000" disappears, ".500" becomes ".5"),
- at most 9 fractional digits (java.time's nanosecond precision;
  more don't parse),
- offset "Z" or a nonzero "±hh:mm" within java.time's ±18:00 range
  (zero offsets format back as "Z", larger ones don't parse),
- uppercase "T" and "Z" (lowercase forms format back in uppercase),
- no Feb 29 outside leap years (java.time refuses to parse it).

This only affects inference from JSON samples — JSON Schema's
"format": "date-time" maps to OffsetDateTime regardless, which is the
correct behavior for schema-driven input.

The nine date-time-related misc-JSON skips on the Kotlin fixtures are
lifted; every date/time-like string in the test inputs that the new
recognizer accepts was verified to round-trip byte-identically through
java.time (5692 strings checked). 77392.json and b4865.json stay
skipped for kotlinx only, for the unrelated top-level-JsonArray reason.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

feat(kotlin): Support for date and datetime from JSON schema

Fixes for the header/source split feature (header-only=false):

- startSourceFile now takes the header filename at every call site and
  derives the source filename itself.  Previously the multi-source call
  sites passed the source filename, so every generated .c file began
  with an unguarded self-include (#include <ClassName.c>) that made
  compilation recurse infinitely.
- The redundant unconditional emitIncludeLine(headerFilename, true)
  after startSourceFile is gone.  In header-only mode it made every
  generated header include itself (an unintended change to the
  pre-existing multi-source output); in split mode it duplicated the
  include emitted by startSourceFile.
- The source file's include of its own header is now a quoted include,
  matching the existing convention: quoted includes for generated
  files, angle brackets only for system and vendored headers.
- getSourceNameFromHeaderName anchors the extension swap (/\.h$/), so
  a header named my.house.h maps to my.house.c, not my.couse.h.
- The header-only option is a BooleanOption instead of a string
  EnumOption, giving the usual --[no-]header-only CLI flags.
- The five duplicated finishHeaderFile/finishSourceFile blocks are
  factored into finishCurrentFile, and a comment typo is fixed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

- The vendored dependencies (cJSON, hashtable, list) are downloaded
  into a deps/ subdirectory and included with -isystem instead of -I..
  Angle-bracket includes now resolve only in deps/, while quoted
  includes resolve relative to the including file, so a generated
  #include <TopLevel.h> fails to compile and the include-style
  convention is enforced by the build.
- second.c is a second translation unit including TopLevel.h.  It is
  compiled and linked in the split-mode compile commands, verifying
  that split output supports multi-TU builds (issue #2617).
- Three minimal mode fixtures run one complex input (nbl-stats.json,
  which produces enums, unions and 22 type pairs) through the
  remaining option combinations:
    - cjson-default: single-source, header-only (the pre-existing
      default output mode)
    - cjson-multi-header: multi-source, header-only (single TU;
      header-only output cannot link from multiple TUs)
    - cjson-multi-split: multi-source with header/source pairs,
      compiled with *.c so every generated source file is linked
- The cjson comment-injection target's output is TopLevel.h; with
  header-only=false a proposed filename of TopLevel.c would have named
  both generated files TopLevel.c.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Renders a small input through the quicktype API and asserts, for the
multi-source modes, that every header gets a source file, that no
generated file includes itself, that generated files are referenced
with quoted includes (never angle brackets), that each source file
includes its own header first, and that header-only mode emits no
source files.  Also pins the output filenames for a proposed filename
with an inner ".h" (my.house.h -> my.house.c).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

[FEATURE]: cJSON - generate source/header pairs